In a network management system (NMS) alarms may be triggered for a variety of reasons, such as failure of a link. An alarm is a notification of a specific event, such as a change of port status. An alarm may or may not represent an error. These alarms are presented to an operator performing network administration functions so that the operator may take action to correct the underlying cause of the alarm, if any such action is required.
These alarms contain standard parameters containing standardized information, and are typically presented to an operator as a line of text in a window. Multiple alarms are presented as multiple lines of text in the same window. While straightforward, this can result in alarms being presented to the operator as too much information too quickly, especially if a fault in the network results in generation of many simultaneous alarms. Alarms may scroll off the window before the operator has an opportunity to examine the information contained in the alarm text. The operator can filter the alarms somewhat by setting attributes in column headers, for example, but the filtering functions on typical NMSs are limited. Furthermore, switching between sets of filtered alarms requires editing an existing filter or retrieving a filter saved to the operator's client hard drive, at which point the single window refreshes with the new set of filtered alarms.
The standard parameters of alarms includes a field called “additional text”. This field is typically used by an NMS server to enter non-configurable information regarding the alarm in the form of notes, notes which an operator may use when looking at an alarm again at a later time. This field provides a heretofore unrealized opportunity to store additional information automatically for use by operators.
A method of displaying alarms to operators in a way which allowed them to see all relevant information at a desired pace would allow the underlying causes of the alarms to be dealt with more efficiently.